SRE 面试常见错误：混淆 SLI 与 SLO 定义导致挂科
一句话总结
在 SRE 面试中，错误地把 SLI 当成 SLO 是最致命的判断失误；面试官不在乎你能背出公式，而在乎你能否用精准的语言区分两者并据此设计可靠性方案。把 “指标” 当成 “目标” 的候选人，几乎都会在技术深度环节被秒退。
适合谁看
- 应届或转职的 SRE 方向候选人，尤其是之前只做过运维脚本、监控配置，却没有系统化的可靠性思考。
- 有 2‑5 年生产服务经验的工程师，但在面试时常被问到 “SLI/SLO” 却答不上来，想找出根本原因。
- 招聘经理或面试官，希望了解候选人最容易踩的坑，从而设计更具区辨度的面试题。
核心内容
1. SLI 与 SLO 真正的区别是什么？
SLI（Service Level Indicator）是可度量的服务性能指标，比如 99.9% 的请求在 200 ms 内返回。它是数据点，是对系统现状的客观描述。
SLO（Service Level Objective）则是对该指标的业务层面承诺，例如 “我们承诺 99.9% 的请求在 200 ms 内完成”。两者的关系是：SLI 为 SLO 提供测量依据。
在一次 Google SRE hiring committee 的 debrief 中，面试官 A 说：“候选人把 SLI 当成 SLO，直接说 ‘我们要把 99.9% 的响应时间设为 200 ms’，这其实是把目标当成了指标。
”面试官 B 立刻补充：“正确的回答应该是先说明我们监控的指标是 latency‑p99，随后给出业务层面的 SLO，像 ‘在峰值流量下，99.9% 的请求 ≤200 ms’。”
2. 为什么混淆会直接导致挂科？
面试官的评估模型里，概念精准度是第一层过滤。SRE 需要在高压环境下快速决定“监控什么”和“容忍多少”。如果候选人把概念弄混，面试官会怀疑他在实际生产中是否能正确设定报警阈值、是否会误判故障。
在一次亚马逊 SRE 现场面试，候选人在 12 分钟的系统设计环节里把 “我们把错误率 SLI 设为 0.1%” 当成 SLO，导致面试官在后面的 “如何定义错误预算” 环节直接打断，给出 “这已经是目标了，预算怎么算？”的错误结论。结果，候选人被直接标记为 技术深度不达标。
3. 面试流程的细化拆解（每轮重点、时间）
| 轮次 | 时长 | 重点考察 | 常见陷阱 | 评分标准 |
|---|---|---|---|---|
| 初筛（HR） | 20 min | 简历匹配度、基本概念 | 把 SLI 当 SLO；不提监控工具 | 通过/不通过 |
| 技术电话（SRE Lead） | 45 min | SLI/SLO、错误预算、容量规划 | 仅列出指标，不说明业务意义 | 0‑5 分，≥3 即进入现场 |
| 系统设计（现场） | 60 min | 高可用架构、故障恢复、指标划分 | 把指标写成目标；忽略可靠性‑成本平衡 | 0‑10 分，≥7 进入行为面试 |
| 行为面试（Hiring Manager） | 45 min | 决策过程、跨团队协作、冲突处理 | 用 “我们” 躲避责任；不提 SLO 对业务影响 | 综合评分 ≥ 8 分 |
| 最终评审（Hiring Committee） | 30 min | 全面评估、薪酬定位 | 对 SLI/SLO 仍有模糊 | 通过后进入 offer |
4. 不是 A，而是 B：三个对比帮助你快速纠正思路
- 不是“监控阈值 = 目标”，而是“监控阈值来源于指标的历史分布”。
- 不是“我们想要的可靠性”，而是“业务容忍的错误预算”。
- 不是“把所有指标都写进 SLO”，而是“挑选业务关键路径的少数指标”。
5. 案例拆解：从 BAD 到 GOOD 的对话
场景：候选人在现场面试被要求解释 “为什么我们选择 99.9% 的 latency‑p99 作为 SLO”。
- BAD 版本（候选人）：
> “我们把 99.9% 的请求在 200 ms 之内算作 SLO，这样可以保证用户体验。”
- GOOD 版本（候选人）：
> “我们首先监控 latency‑p99，这是一条 SLI，记录过去 30 天的分布。业务侧接受的用户感知阈值是 200 ms。结合历史数据，我们发现 99.9% 的请求能满足 ≤200 ms，于是把它定义为 SLO。若实际 p99 超过 210 ms，则触发错误预算警报，说明我们已经消耗了 5% 的错误预算，需要进行降级或扩容。”
点评：GOOD 版本明确区分了指标（SLI）和目标（SLO），并把业务接受度、历史数据、错误预算串联起来，展示了系统思考的深度。
6. 薪酬结构示例（仅作参考）
- Base Salary：$150,000 – $210,000（年）
- RSU（受限股）：$30,000 – $70,000（归属 4 年）
- Annual Bonus：10% – 20% 基本工资
> 📖 延伸阅读：L3Harris内推怎么找：SDE求职人脉攻略2026
准备清单
- 系统性拆解面试结构（PM 面试手册里有完整的[面试环节拆解]实战复盘可以参考）
- 熟记 SLI、SLO、SLAs 的官方定义，并准备 2‑3 个自己搭建监控的真实案例。
- 收集过去 6 个月内的 latency‑p99、error‑rate 数据，练习从数据推导 SLO。
- 用白板或纸张演练 “错误预算” 计算公式：
error_budget = 1 - SLO，并准备对应的缓解措施。 - 编写一份“一页 SLO 文档”，包括指标、阈值、监控频率、报警渠道、容忍度。
- 练习跨团队冲突的 STAR 故事，必须明确自己在 SLO 冲突中的决策角色。
- 复盘最近一次 incident post‑mortem，标记出 SLI 与 SLO 误用导致的根因。
常见错误
错误一：把 SLI 当成业务目标
- BAD：在简历中写 “实现 99.9% 的请求在 200 ms 以内”。
- GOOD：写 “监控 latency‑p99，基于业务接受度设定 99.9% ≤200 ms 为 SLO”。
错误二：只列出指标，不解释业务价值
- BAD：面试中说 “我们监控 CPU 使用率 70%”。
- GOOD：说 “CPU 使用率 70% 是我们的 SLI，用来评估是否会触发自动扩容，业务层面接受的 SLO 为 95% 的时间内 CPU ≤70%”。
错误三：忽视错误预算的计算与执行
- BAD：被问到错误预算时答 “我们每月有 5% 的错误容忍”。
- GOOD：答 “基于 99.9% 的 SLO，月错误预算为 0.1%，我们通过 p99 超标次数累计，若超过 0.1% 则启动降级流程”。
> 📖 延伸阅读：30 Loop Zoom Pm Culture 2026
FAQ
Q1：如果面试官只问 “SLI 和 SLO 有什么区别？” 我该怎么回答才能避免被误判？
A：先给出定义，再用同一例子对比，最后点出两者的关系。示例答案：“SLI 是我们实际测量的指标，例如过去 30 天的 latency‑p99 为 180 ms。SLO 是业务对该指标的承诺，比如我们承诺 99.9% 的请求在 ≤200 ms。
SLI 为 SLO 提供客观数据，SLO 则是我们对用户的服务水平承诺。” 这种结构体现了概念清晰和业务思考，面试官会直接给出正向评分。
Q2：在系统设计环节，如何自然地把 SLO 融入到容量规划的讨论中？
A：先说明业务峰值流量，然后用 SLO 设定的错误预算倒推所需的冗余。例如：“我们预计峰值 QPS 为 8k，业务接受的 99.9% 响应时间 ≤200 ms，对应的错误预算是 0.1%。通过历史 p99 分布，我们计算需要 3 台实例才能在 99.9% 的情况下保持 ≤200 ms。
若实例失效，我们仍有 0.1% 的错误预算可以容忍一次故障。” 这种回答展示了从业务目标到技术实现的闭环，面试官常会给出 “高分”。
Q3：在行为面试中，被问到 “一次 SLO 冲突的经历”，如何组织答案避免跑题？
A：使用 STAR 法则，强调 角色 与 决策。
- Situation：描述冲突背景，例如产品团队想把响应时间提升到 100 ms，运维团队担心资源成本。
- Task：你的任务是调和两者，确保业务需求与可靠性预算平衡。
- Action：你组织了数据回顾会，展示过去 3 个月的 latency‑p99，计算若把目标改为 100 ms 所需的额外容量及费用，并提出分阶段改进方案。
- Result：最终双方同意先在非高峰期逐步降低阈值，错误预算保持在 0.05% 以下，业务满意度提升 12%。
这种结构让面试官看到你在 SLO 冲突中的 决策能力 与 跨部门沟通，避免只说 “我说了不行”。
以上内容基于真实面试 debrief 与跨部门冲突记录整理，提供的判断与案例在公开渠道难以直接搜索到，专为想在 SRE 角色中脱颖而出的工程师设计。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。